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(54) Methods, apparatus, and product for managing resources 



(57) In accordance with the present invention a 
process is provided for allocating and deallocating re- 
sources in a distributed processing system having a re- 
quester platform and a server platform. The process in- 
volves receiving a request from the requestor platform 
referring to a system resource and specifying a request- 
ed lease period, permitting shared access to the system 
resource for a lease period, sending a return call to the 
requestor platform advising of the lease period, and 
deallocating the system resource when the lease period 
expires. 
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Description 

Technical Field 

This invention generally relates to garbage codec- s 
lion for computer systems and, more particularly, to a 
fault-tolerant distributed garbage collection method for 
collecting resources bound to or associated with refer- 
ences 
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Proper resource management is an important as- 
pect to efficient and effective use of computers. In gen- 
■ eral, resource management involves allocating resourc- is 
es (e.g., memory) in response to requests as well as 
deallocating resources at appropriate times, for exam- 
ple, when the requesters no longer require the resourc- 
es. In general, the resources contain data referenced by 
computational . entities (e.g., applications, programs, 20 
applets, etc.) executing in the computers. 

In practice, when applications executing on com- 
puters seek to refer to resources, the computers must 
first allocate or designate resources so that the applica- 
tions can properly refer to them. When the applications 25 
no longer refer to a resource, the computers can deal- 
locate or reclaim the resource for reuse. In computers 
each resource has a unique "handle" by which the re- 
source can be referenced. The handle may be imple- 
mented in various ways, such as an address, array in- 30 
dex, unique value, pointer, etc. 

Resource management is relatively simple for a sin- 
gle computer because the events indicating when re- 
sources can be reclaimed, such as when applications 
no longer refer to them or after a power failure, are easy 35 
to determine. Resource management for distributed 
systems connecting multiple computers is more difficult 
because applications in several different computers 
may be using the same resource. 

Disconnects in distributed systems can lead to the 40 
improper and premature reclamation of resources or to 
the failure to reclaim resources. For example, multiple 
applications operating on different computers in a dis- 
tributed system may refer to resources located on other 
machines. If connections between the computers on 45 
which resources are located and the applications refer- 
ring to those resources are interrupted, then the com- 
puters may reclaim the resources prematurely. Alterna- 
tively, the computers may maintain the resources in per- 
petuity, despite the extended period of time that appli- so 
cations failed to access the resources. 

These difficulties have led to the development of 
systems to manage network resources, one of which is 
known as "distributed garbage collection." That term de- 
scribes a facility provided by a language or runtime sys- $$ 
tern for distributed systems that automatically manages 
resources used by an application or group of applica- 
tions running on different computers in a network. 



In general, garbage collection uses the notiosSjhat 
resources can be freed for future use when they are no 
longer referenced by any pari of an application. Distrib- 
uted garbage collection extends this notion to the realm 
of distributed computing, reclaiming resources when no 
application on any computer refers to them. 

Distributed garbage collection must maintain integ- 
rity between allocated resources and the references to 
those resources. In other words, the system must not 
be permitted to deallocate or free a resource when an 
application running on any computer in the network con- 
tinues to refer to that resource. This reference-to-re- 
source binding, referred to as "referential integrity, ' does 
not guarantee that the reference will always grant ac- 
cess to the resource to which it refers. For example, net- 
work failures can make such access impossible. The in- 
tegrity, however, guarantees that if the reference can be 
used to gain access to any resource, it will be the same 
resource to which the reference was first given. 

Distributed systems using garbage collection must 
also reclaim resources no longer being referenced at 
some time in the finite future. In other words, the system 
must provide a guarantee against "memory leaks." A 
memory leak can occur when all applications drop ref- 
erences to a resource, but the system fails to reclaim 
the resource for reuse because, for example, of an in- 
correct determination that some application still refers 
to the resource. 

Referential integrity failures and memory leaks of- 
ten result from disconnections between applications ref- 
erencing the resources and the garbage collection sys- 
tem managing the allocation and deallocation of those 
resources. For example, a disconnection in a network 
connection between an application referring to a re- 
source and a garbage collection system managing that 
resource may prevent the garbage collection system 
from determining whether and when to reclaim the re- 
source. Alternatively, the garbage collection system 
might mistakenly determine that, since an application 
has not accessed a resource within a predetermined 
time, it may collect that resource. A number of tech- 
niques have been used to improve the distributed gar- 
bage collection mechanism by attempting to ensure that 
such mechanisms maintain referential integrity without 
memory leaks. One conventional approach uses a form 
of reference counting, in which a count is maintained of 
the number of applications referring to each resource. 
When a resource's count goes to zero, the garbage col- 
lection system may reclaim the resource. Such a refer- 
ence counting scheme only works, however, if the re- 
source is created with a corresponding reference coun- 
ter. The garbage collection system in this case incre- 
ments the resource's reference count as additional ap- 
plications refer to the resource, and decrements the 
count when an application no longer refers to the re- 
source. 

Reference counting schemes, however, especially 
encounter problems in the face of failures that can occur 
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in distributed systems. Such failures can take the form 
of a computer or application failure or network failure 
that prevent the delivery of messages notifying the gar- 
bage collection system that a resource is no longer be- 
ing referenced. If messages go undelivered because of 5 
a network disconnect, the garbage collection system 
does not know when to reclaim the resource. 

To prevent such failures, some conventional refer- 
ence counting schemes include "keep-alive" messages, 
which are also referred to as "ping back." According to io 
this scheme, applications in the network send messag- 
es to the garbage collection system overseeing resourc- 
es and indicate that the applications can still communi- 
cate. These messages prevent the garbage collection 
system from dropping references to resources. Failure '5 
to receive such a "keep-alive" message indicates that 
the garbage collection system can decrement the refer- 
ence count for a resource and, thus, when the count 
reaches zero, the garbage collection system may re- 
claim the resource. This, however, can still result in the 20 
premature reclamation of resources following reference 
counts reaching zero from a failure to receive "keep- 
alive" messages because of network failures. This vio- 
lates the referential integrity requirement. 

Another proposed method for resolving referential 2s 
integrity problems in garbage collection systems is to 
maintain not only a reference count but also an identifier 
corresponding to each computational entity referring to 
a resource. See A. Birrell, et al. t "Distributed Garbage 
Collection for Network Objects," No. 116, digital Sys- -30 
terns Research Center, December 15, 1993. This meth- 
od suffers from the same problems as the reference 
counting schemes. Further, this method requires the ad- 
dition of unique identifiers for each computational entity 
referring to each resource, adding overhead that would 3$ 
unnecessarily increase communication within distribut- 
ed systems and add storage requirements (i.e., the list 
of identifiers corresponding to applications referring to 
each resource). 

40 

Disclosure of the Invention 

In accordance with the present invention, referential 
integrity is guaranteed without costly memory leaks by 
leasing resources for a period of time during which the 4 $ 
parties in a distributed system, for example, an applica- 
tion holding a reference to a resource and the garbage 
collection system managing that resource, agree that 
the resource and a reference to that resource will be 
guaranteed. At the end of the lease period, the guaran- so 
tee that the reference to the resource will continue laps- 
es, allowing the garbage collection system to reclaim the 
resource. Because the application holding the reference 
to the resource and the garbage collection system man- 
aging the resource agree to a finite guaranteed lease 55 
period, both can know when the lease and, therefore, 
the guarantee, expires. This guarantees referential in- 
tegrity for the duration of a reference lease and avoids 



the concern of failing to free the resource because of 
network errors. 

In accordance with the present invention, as em- 
bodied and broadly described herein, a method for man- 
aging resources comprises the steps of receiving a re- 
quest from a process referring to a resource and spec- 
ifying a requested lease period, permitting shared ac- 
cess to the resource for a granted lease period, advising 
the process of the granted tease period, and deallocat- 
ing the resource when the granted lease period expires 
In accordance with another aspect of the present inven- 
tion, as embodied and broadly described herein, a meth- 
od for managing resources comprises the steps of re- 
questing from a process access to a resource for a lease 
period, receiving from the process a granted lease pe- 
riod during which shared access to the resource is per- 
mitted, and sending a request to the process for a new 
lease period upon a determination that the granted 
lease period is about to expire but access to the re- 
source has not completed. 

In accordance with the present invention, as em- 
bodied and broadly described herein, an apparatus 
comprises a receiving module configured to receive a 
request from a process referring to a resource and spec- 
ifying a requested lease period, a resource allocator 
configured to permit shared access to the resource for 
a granted lease period, an advising module configured 
to advise the process of the granted lease period, and 
a resource deallocator configured to deallocate the re- 
source when the granted lease period expires. In ac- 
cordance with another aspect of the present invention, 
as embodied and broadly described herein, an appara- 
tus comprises a requesting module configured to re- 
quest from a process access to a resource for a lease 
period, a receiving module configured to receive from 
the process a granted lease period during which shared 
access to the resource is permitted, and a second send- 
ing module configured to send another request to the 
process for a new lease period upon a determination 
that the granted lease period is about to expire but ac- 
cess to the resource has not completed. 

In accordance with yet another aspect of the 
present invention, as embodied and broadly described 
herein, a computer program product comprises a com- 
puter usable medium having computable readable code 
embodied therein for managing resources. The code 
comprises a receiving module configured to receive a 
request from a process referring to a resource and spec- 
ifying a requested lease period, a resource allocator 
configured to permit shared access to the resource for 
a granted lease period, an advising module configured 
to advise of the granted lease period, and a resource 
deallocator configured to deallocate the resource when 
the granted lease period expires. In accordance with an - 
other aspect of the present invention, as embodied and 
broadly described herein, a computer program product 
comprises a computer usable medium having comput- 
able readable code embodied therein for managing re- 
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sources. The code comprises a requesting module con- 
figured to request from a process access to a resource 
for a lease period, a receiving module configured to re- 
ceive from the process a granted lease period during 
which the process permits shared access to the re- 
source, and a sending module configured to send an- 
other request to the process for a new lease period upon 
a determination that the granted lease period is about 
to expire. 

Brief Description of the Drawings 

The accompanying drawings, which are incorporat- 
ed in and constitute a part of this specification, illustrate 
an embodiment of the invention and, together with the 
description, serve to explain the advantages and princi- 
ples of the invention. In the drawings, 

FIG. 1 is a flow diagram of the steps performed by 
the application call processor according to an im- 
plementation of the present invention; 
FIG. 2 is a flow diagram of the steps performed by 
the server call processor to process dirty calls ac- 
cording to the implementation of the present inven- 
tion; 

FIG. 3 is a flow diagram of the steps performed by 
the server call processor to process clean calls ac- 
cording to the implementation of the present inven- 
tion; 

FIG. 4 is a flow diagram of the steps performed by 
the server call processor to initiate a garbage col- 
lection process according to the implementation of 
the present invention. 

FIG. 5 is a diagram of a preferred flow of calls within 
a distributed processing system; 
FIG. 6 is a block diagram of the components of the 
implementation of a method invocation service ac- 
cording to the present invention; 
FIG. 7 is a diagram of a distributed processing sys- 
tem that can be used in an implementation of the 
present invention; and 

FIG. 8 is a diagram of the individual software com- 
ponents in the platforms of the distributed process- 
ing system according to the implementation of the 
present invention. 

Best Mode for Carrying Out the Invention 

Reference will now be made in detail to an imple- 
mentation of the present invention as illustrated in the 
accompanying drawings. Wherever possible, the same 
reference numbers will be used throughout the drawings 
and the following description to refer to the same or like 
parts. 

The present invention may be implemented by com- 
puters organized in a conventional distributed process- 
ing system architecture. The architecture for and proce- 
dures to implement this invention, however, are not con- 
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ventional, because they provide a distributed garbage 
collection scheme that ensures referential integrity and 
eliminates memory leaks. 

5 A. Overview 



A method invocation (Ml) component located in 
each of the computers in the distributed processing sys- 
tem implements the distributed garbage collection 
scheme of this invention. The Ml component may con- 
sist of a number of software modules preferably written 
in the JAVA™ programming language. 

In general, whenever an application in the distribut- 
ed processing system obtains a reference to a distrib- 
uted resource, by a name lookup, as a return value to 
some other call, or another method, and seeks to access 
the resource, the application makes a call to the re- 
source or to an Ml component managing the resource, 
That Ml component, called a managing Ml component, 
keeps track of the number of outstanding references to 
the resource. When the number of references to a ref- 
erence is zero, the managing Ml component can reclaim 
the resource. The count of the number of references to 
a resource is generally called the 'reference count" and 
the call that increments the reference count may be re- 
ferred to as a "dirty call." 

When an application no longer requires a distribut- 
ed resource, it sends a different call to the resource or ' 
the managing Ml component. Upon receipt of this call, 
the managing Ml component decrements the reference 
count for the resource. This call to drop a reference may 
be referred to as a "clean call." 

In accordance with an implementation of the 
present invention, a dirty call can include a requested 
time interval, called a lease period, for the reference to 
the resource. Upon receipt of the dirty call, the managing 
Ml component sends a return call indicating a period for 
which the lease was granted. The managing Ml compo- 
nent thus tracks the lease period for those references 
as well as the number of outstanding references. Con- 
sequently, when the reference count for a resource goes 
to zero or when the lease period for the resource ex- 
pires, the managing Ml component can reclaim the re- 
source. 



50 



55 



B. Procedure 

An application call processor in an Ml component 
performs the steps of the application call procedure 100 
illustrated in FIG. 1. The server call processor in the 
managing Ml component performs the steps of the pro- 
cedures 200. 300, and 400 illustrated in FIGs. 2-4. re- 
spectively. The managing Ml component's garbage col- 
lector performs conventional procedures to reclaim re- 
sources previously bound to references in accordance 
with instructions from the server call processor. Accord- 
ingly, the conventional procedures of the garbage col- 
lector will not be explained. 



4 



7 

1. Application Call Processor 

FIG. 1 is a flow diagram of the procedure 100 that 
the application call processor of the Ml component uses 
to handle application requests for references to resourc- s 
es managed by the same or another Mi component lo- 
cated in the distributed processing system. 

After an application has obtained a reference to a 
resource, the application call processor sends a dirty 
call, including the resource's reference and a requested *o 
lease period to the managing Ml component for the re- 
source (step 110). The dirty call may be directed to the 
resource itself or to the managing Ml component. 

The application call processor then waits for and re- 
ceives a return call from the managing Ml component is 
(step 120). The return call includes a granted lease pe- 
riod during which the managing Ml component guaran- 
tees that the reference of the dirty call will be bound to 
its resource. In other words, the managing Ml compo- 
nent agrees not to collect the resource corresponding 20 
to the reference of a dirty call for the grant period. If the 
managing Ml component does not provide a grant peri- 
od, or rejects the request for a lease, then the application 
call processor will have to send another dirty call until it 
receives a grant period. 25 

The application call processor monitors the applica- 
tion's use of the reference and, either when the applica- 
tion explicitly informs the application call processor that 
the reference is no longer required or when the applica- 
tion call processor makes this determination on its own 30 
(step 130), the application call processor sends a clean 
call to the managing Ml component (step 1 40). In a man- 
ner similar to the method used for dirty calls, the clean 
call may be directed to the referenced resource and the 
managing Ml component will process the clean call. 35 
Subsequently, the application call processor eliminates 
the reference from a list of references being used by the 
application (step 150). 

If the application is not yet done with the reference 
(step 1 30), but the application call processor determines 40 
that the grant period for the reference is about to expire 
(step 160), then the application call processor repeats 
steps 110 and 120 to ensure that the reference to the 
resource is maintained by the managing Ml component 
on behalf of the application. 45 

2. Server Call Processor 

The Ml component's server call processor performs 
three main procedures: (1 ) handling dirty calls. (2) han- so 
dling incoming clean calls: and (3) initiating a garbage 
collection cycle to reclaim resources at the appropriate 
time. 

(i) Dirty Calls 55 

FIG. 2 is a flow diagram of the procedure 200 that 
the Ml component's server call processor uses to handle 
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requests to reference resources, i.e.. dirty calls, that the 
Ml software component manages. These requests 
come from application call processors of Ml compo- 
nents in the distributed processing system, including the 
application call processor of the same Ml component as 
the server call processor handling requests. 

First, the server call processor receives a dirty call 
(step 210). The server call processor then determines 
an acceptable grant period (step 220). The grant period 
may be the same as the requested lease period or some 
other time period. The server call processor determines 
the appropriate grant period based on a number of con- 
ditions including the amount of resource required and 
the number of other grant periods previously granted for 
the same resource. 

When the server call processor determines that a 
resource has not yet been allocated for the reference of 
a dirty call (step 230), the server call processor allocates 
the required resource (step 240). 

The server call processor then increments a refer- 
ence count corresponding to the reference of a dirty call 
(step 250), sets the acceptable grant period for the ref- 
erence-to-resource binding (step 260), and sends a re- 
turn call to an application call processor with the grant 
period (step 270). In this way, the server call processor 
controls incoming dirty calls regarding references to re- 
sources under its control. 

Applications can extend leases by sending dirty 
calls with an extension request before current leases ex- 
pire. As shown in procedure 200, a request to extend a 
lease is treated just like an initial request for a lease. An 
extension simply means that the resource will not be re- 
claimed for some additional interval of time, unless the 
reference count goes to zero. 

(ii) Clean Calls 

The Ml component's server call processor also han- 
dles incoming clean calls from application call proces- 
sors. When an application in the distributed processing 
system no longer requires a reference to a resource, it 
informs the Ml component managing the resource for 
that reference so that the resource may be reclaimed 
for reuse. Fig. 3 is a flow diagram ofthe procedure 300 
With the steps that the Ml component's server call proc- 
essor uses to handle clean calls. 

When the server call processor receives a clean call 
with a reference to a resource that the Ml component 
manages (step 310), the server call processor decre- 
ments a corresponding reference count (step 320). The 
clean call may be sent to the resource, with the server 
call processor monitoring the resource and executing 
the procedure 300 to process the call. Subsequently, the 
server call processor sends a return call to the Ml com- 
ponent that sent the clean call to acknowledge receipt 
(step 330). In accordance with this implementation of 
the present invention, a clean call to drop a reference 
may not be refused, but it must be acknowledged. 
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(iii) Garbage Collection 

The server call processor also initiates a garbage 
. collection cycle to reclaim resources for which it deter- 
mines that either no more references are being made to 5 
the resource or that the agreed lease period for the re- 
source has expired. The procedure 400 shown in FIG. 
4 includes a flow diagram of the steps that the server 
call processor uses to initiate a garbage collection cycle. 

The server call processor monitors reference ic 
counts and granted lease periods and determines 
whether a reference count is zero for a resource man- 
aged by the Ml component, or the grant period for a ref- 
erence has expired (step 410). When either condition 
exists, the server call processor initiates garbage col- 
lection (step 420) of that resource. Otherwise, the server 
call processor continues monitoring the reference 
counts and granted lease periods. 

C. Call Flow 20 

FIG. 5 is a diagram illustrating the flow of calls 
among Ml components within the distributed processing 
system. Managing Ml component 525 manages the re- 
sources 530 by monitoring the references to those re- 25 
sources 530 (see garbage collect 505). Because the 
managing Ml components 525 manages the resources, 
the server call processor of managing Ml component 
525 performs the operations of this call flow description. 

FIG. 5 also shows that applications 510 and 540 30 
have corresponding Ml components 515 and 545, re- 
spectively. Each of the applications 510 and 540 obtains 
a reference to one of the resources 530 and seeks to 
obtain access to one of the resources 530 such that a 
reference is bound to the corresponding resource. To 35 
obtain access, applications 510 and 540 invoke their 
corresponding Ml components 51 5 and 545, respective- 
ly, to send dirty calls 551 and 571 , respectively, to the 
Ml component 525. Because the Ml components 515 
and 525 handle application requests for access to re- 40 
sources 530 managed by another Ml component, such 
as managing Ml component 525, the application call 
processors of Ml components 515 and 545 perform the 
operations of this call flow description. 

In response to the dirty calls 551 and 571, managing *s 
Ml component 525 sends return calls 552 and 572, re- 
spectively, to each of the Ml components 515 and 545, 
respectively. The dirty calls include granted lease peri- 
ods for the references of the dirty calls 551 and 571 . 

Similarly, FIG. 5 also shows Ml components 515 so 
and 545 sending clean calls 561 and 581 , respectively, 
to managing Ml component 525. Clean calls 561 and 
581 inform managing Ml component 525 that applica- 
tions 510 and 540, respectively, no longer require ac- 
cess to the resource specified in the clean calls 561 and ss 
581. Managing Ml component 525 responds to clean 
calls 561 and 581 with return calls 562 and 582, respec- 
tively. Return calls 562 and 582 differ from return calls 



552 and 572 in that return calls 562 and 582 are simply 
acknowledgments from Ml component 525 of the re- 
ceived clean calls 561 and 581 . 

Both applications 510 and 540 may request access 
to the same resource. For example, application 510 may 
request access to *RESOURCE(1 )" while application 
540 was previously granted access to that resource. Ml 
component 525 handles this situation by making the re- 
source available to both applications 510 and 540 for 
' agreed lease periods. Thus, Ml component 525 will not 
initiate a garbage collection cycle to reclaim the "RE- 
SOURCE(1 )" until either applications 510 and 540 have 
both dropped their references to that resource or the lat- 
est agreed periods has expired, whichever event occurs 
first. 

By permitting more than one application to access 
the same resource simultaneously the present inven- 
tion also permits an application to access a resource af- 
ter it sent a clean call to the managing Ml component 
dropping the reference to the resource. This occurs be- 
cause the resource is still referenced by another appli- 
cation or the reference's lease has not yet expired so 
the managing Ml component 525 has not yet reclaimed 
the resource. The resource, however will be reclaimed 
after a finite period, either when no more applications 
have leases or when the last lease expires. 

D. Ml Components 

FIG. 6 is a block diagram of the modules of an Ml 
component 600 according to an implementation of the 
present invention. Ml component 600 can include a ref- 
erence component 605 for each reference monitored, 
application call processor 640, server call processor 
650, and garbage collector 660. 

Reference component 605 preferably constitutes a 
table or comparable structure with reference data por- 
tions 610, reference count 620, and grant period register 
630. Ml component 600 uses the reference count 620 
and grant period 630 for each reference specified in a 
corresponding reference data portion 610 to determine 
when to initiate garbage collector 660 to reclaim the cor- 
responding resource. 

Application call processor 640 is the software mod- 
ule that performs the steps of procedure 100 in FIG. 1. 
Server call processor 650 is the software module that 
performs the steps of procedures 200, 300, and 400 in 
FIGs. 2-4. Garbage collector 660 is the software module 
that reclaims resources in response to instructions from 
the server call processor 650 as explained above. 

E. Distributed Processing System 

FIG 7 illustrates a distributed processing system 50 
which can be used to implement the present invention. 
In FIG. 7, distributed processing system 50 contains 
three independent and heterogeneous platforms 100, 
200, and 300 connected in a network configuration rep- 
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resented by the network cloud 55. The composition and 
protocol of the network configuration represented in 
FIG. 7 by the cloud 55 is not important as long as it al- 
lows for communication of the information between plat- 
forms 700. S00 and 900. In addition, the use of just three 5 
platforms is merely for illustration and does not limit the 
present invention to the use of a particular number of 
platforms. Further, the specific network architecture is 
not crucial to this invention. For example, another net- 
work architecture that could be used in accordance with io 
this invention would employ one platform as a network 
controller to which all the other platforms would be con- 
nected. 

In the implementation of distributed processing sys- 
tem 50, platforms 700, 800 and 900 each include a proc- 
essor 710, 810. and 910 respectively, and a memory, 
750, 850, and 950, respectively. Included within each 
processor 710, 8 10, and 9 10, are applications 720, 820, 
and 920, respectively, operating systems 740. 840, and 
940, respectively, and Ml components 730, 830, and 20 
930, respectively. 

Applications 720, 820, and 920 can be programs 
that are either previously written and modified to work 
with the present invention, or that are specially written 
to take advantage of the services offered by the present 2s 
invention. Applications 720, 820, and 920 invoke oper- 
ations to be performed in accordance with this invention. 

Ml components 730, 830, and 930 correspond to 
the Ml component 600 discussed above with reference 
to FIG. 6. 30 

Operating systems 740, 840, and 940 are standard 
operating systems tied to the corresponding processors 
710,810, and 910, respectively. The platforms 700, 800, 
and 900 can be heterogenous. For example, platform 
700 has an UltraSparc® microprocessor manufactured 35 
by Sun Microsystems Corp. as processor 710 and uses 
a Solaris® operating system 740. Platform 800 has a 
MIPS microprocessor manufactured by Silicon Graph- 
ics Corp. as processor 810 and uses a Unix operating 
system 840. Finally, platform 900 has a Pentium micro- *o 
processor manufactured by Intel Corp. as processor 
910 and uses a Microsoft Windows 95 operating system 
940. The present invention is not so limited and could 
accommodate homogenous platforms as well. 

Sun, Sun Microsystems, Solaris, Java, and the Sun 4 $ 
Logo are trademarks or registered trademarks of Sun 
Microsystems, Inc. in the United States and other coun- 
tries. UltraSparc and all other SPARC trademarks are 
used under license and are trademarks of SPARC Inter- 
national, Inc. tn the United States and other countries, so 
Products bearing SPARC trademarks are based upon 
an architecture developed by Sun Microsystems, Inc. 

Memories 750 T 650 : and 950 serve several func- 
tions, such as general storage for the associated plat- 
form. Another function is to store applications 720, 820, 55 
and 920, Ml components 730, 830. and 930, and oper- 
ating systems 740. 840, and 940 before execution by 
the respective processor 7 1 0, 8 1 0. and 9 1 0. In addition. 



portions of memories 750, S50, and 950 may constitute 
shared memory available to all of the platforms 700. 
800. and 900 in network 50. 

E. Ml Services 

The present invention may be implemented using a 
client/server model. The client generates requests, such 
as the dirty calls and clean calls, and the server re- 
sponds to requests. 

Each of the Ml components 730. 630 and 930 
shown in FIG. 7 preferably includes both client compo- 
nents and server components. FIG. 8. which is a block 
diagram of a client platform 1000 and a server platform 
1100, applies to any two of the platforms 700, 800, and 
900 in FIG. 7. 

Platforms 1000 and 1100 contain memories 1050 
and 1150, respectively, and processors 1 010 and 1110, 
respectively. The elements in the platforms 1000 and 
1100 function in the same manner as similar elements 
described above with reference to FIG. 7. In this exam- 
ple, processor 1010 executes a client application 1020 
and processor 1110 executes a server application 1 1 20. 
Processors 1010 and 1110 also execute operating sys- 
tems 1040 and 1140, respectively, and Ml components 
1030 and 1130, respectively. 

Ml components 1030 and 11 30 each include a serv- 
er call processor 1031 and 1131, respectively, an appli- 
cation call processor 1032 and 1132, respectively, and 
a garbage collector 1033 and 1133, respectively. Each 
of the Ml components 1030 and 11 30 also contains ref- 
erence components, including reference data portions 
1 034 and 1 1 34, respectively, reference counts 1 035 and 

1135, respectively, and grant period registers 1036 and 

1136, respectively, for each reference that the respec- 
tive Ml component 1030 or 1130 monitors. 

Application call processors 1032 and 1132 repre- 
sent the client service and communicate with server call 
processors 1031 and 1131, respectively, which repre- 
sent the server service. Because platforms 1000 and 
1100 contain a server call processor, an application call 
processor, a garbage collector, and reference compo- 
nents, either platform can act as a client or a server. 

For purposes of the discussion that follows, howev- 
er, platform 1000 is designated the client platform and 
platform 1100 is designated as the server platform. In 
this example, client application 1 020 obtains references 
to distributed resources and uses Ml component 1030 
to send dirty calls to the resources managed by Ml com- 
ponent 1 1 30 of server platform 1 1 00. 

Additionally, server platform 1 1 00 may be executing 
a server application 11 20. Server application 1120 may 
also use Ml component 1130 to send dirty calls which 
may be handled by Ml component 1130 when the re- 
sources of those dirty calls are managed by Ml compo- 
nent 1130. Alternatively, server application 1120 may 
use Ml component 1 1 30 to send dirty calls to resources 
managed by Ml component 1030. 
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Accordingly, server call processor 1031, garbage 
collector 1033, and reference count 1035 for Ml compo- 
nent 1030 of client platform 1000 are not active and are 
therefore presented in FIG. 6 as shaded. Likewise, ap- 
plication call processor 1132 of Ml component 1130 of s 
the server platform 1100 is shaded because it is also 
dormant. 

When client application 1020 obtains a reference 
corresponding to a resource, application call processor 
1 032 sends a dirty call, which server call processor 1131 10 
receives. The dirty call includes a requested lease peri- 
od. Server call processor 1131 increments the reference 
count 1135 for the reference in the dirty call and deter- 
mines a grant period. In response, server call processor 
1 1 31 sends a return call to application call processor '5 
1030 with the grant period. Application call processor 
1 032 uses the grant period to update recorded grant pe- 
riod 1035, and to determine when the resource corre- 
sponding to the reference of its dirty call may be re- 
claimed. 20 

Server call processor 1131 also monitors the refer- 
ence counts and grant periods corresponding to refer- 
ences for resources that it manages. When one of its 
reference counts 11 35 is zero, or when the grant period 
1135 for a reference has expired, whichever event oc- 25 
curs first, server call processor 1131 may initiate the gar- 
bage collector 1 1 33 to reclaim the resource correspond- 
ing to the reference that has a reference count of zero 
or an expired grant period. 

The leased-reference scheme according to the im- 30 
plementation of the present invention does not require 
that the clocks on the platforms 1000 and 1100 involved 
in the protocol be synchronized. The scheme merely re- 
quires that they have comparable periods of increase. 
Leases do not expire at a particular time, but rather ex- 3S 
pire after a specific time interval. As long as there is ap- 
proximate agreement on the interval, platforms 1000 
and 1 1 00 will have approximate agreement on the grant- 
ed lease period. Further, since the timing for the lease ' 
is, in computer terms, fairly long, minor differences in 40 
clock rate will have little or no effect. 

The transmission time of the dirty call can affect the 
protocol. If Ml component 1030 holds a lease to refer- 
ence and waits until just before the lease expires to re- 
quest a renewal, the lease may expire before the Ml *s 
component 1 1 30 receives the request. If so, Ml compo- 
nent 1 1 30 may reclaim the resource before receiving the 
renewal request. Thus, when sending dirty calls, the 
sender should add a time factor to the requested lease 
period in consideration of transmission time to the plat- so 
form handling the resource of a dirty call so that renewal 
dirty calls may be made before the lease period for the 
resource expires. 

F. Conclusion 55 

In accordance with the present invention a distrib- 
uted garbage collection scheme ensures referential in- 



tegrity and eliminates memory leaks by providing grant- 
ed lease periods corresponding to references to re- 
sources in the distributed processing system such that 
when the granted lease periods expire, so do the refer- 
ences to the resources. The resources may then be col- 
lected. Resources may also be collected when they are 
no longer being referenced by processes in the distrib- 
uted processing system with reference to counters as- 
signed to the references for the resources. 

The foregoing description of an implementation of 
the invention has been presented for purposes of illus- 
tration and description. It is not exhaustive and does not 
limit the invention to the precise form disclosed. Modifi- 
cations and variations are possible in light of the above 
teachings or may be acquired from prac.eing of :ho in- 
vention. For example, the described implementation in- 
cludes software but the present invention may be imple- 
mented as a combination of hardware at. 6 software c< 
in hardware alone. The scope of the invention is defined 
by the claims and their equivalents. 



Claims 

1. A method for managing resources comprising the 
steps of: 

receiving a request from a process referring to 
a resource and specifying a requested lease 
period; 

permitting shared access to the resource for a 
granted lease period; 

advising the process of the granted lease peri- 
od; and 

deallocating the resource when the granted 
lease period expires. 

2. The method of claim 1 , wherein the permitting step 
includes the substep of: 

determining the granted lease period to be a 
period less than the requested lease period. 

3. The method of claim 1 , wherein the permitting step 
includes the substep of: 

determining the granted lease period based 
on at least one of the requested lease period, a 
measure of the resource, and other granted lease 
periods for the resource. 

4. The method of claim 1 , wherein the permiiting step 
includes the substep of: 

allocating the resource upon a determination 
that it was not previously allocated. 

5. The method of claim 1 , wherein the permitting step 
includes the substep of. 

incrementing a reference count correspond- 
ing to the resource, the reference count indicating 
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how many processes currently have references to 
the resource. 

6. The method of claim 5. further comprising the step 
of: 

receiving a second request from the process in- 
dicating that the process wishes to terminate its 
access to an identified resource; and 
decrementing the reference count correspond- 
ing to the identified resource. 

7. The method of claim 1, wherein the deallocating 
step includes the substep of: 

invoking a garbage collection process to re- 
claim the resource when shared access to the re- 
source is no longer requested. 

8. The method of claim 6, wherein the deallocating 
step includes the substep of: 

invoking a garbage collection process to deal- 
locate the identified resource when the reference 
count indicates no processes currently access the 
identified resource. 

9. A method for managing resources comprising the 
steps of: 



1 2. The apparatus of claim 1 1 , wherein the resource al- 
locator includes: 

a determining module configured to Deter- 
mine the granted lease period to be a period iess 
s than the requested lease period. 

1 3. The apparatus of claim 1 1 , wherein the resource al- 
locator includes: 

a determining module configured to deter- 
io mine the granted lease period based on at least one 
of the requested lease period, a measure of the re- 
source, and other granted lease periods for the re- 
source. 

'5 1 4. The apparatus of cfaim 1 1 , wherein the resource al- 
locator includes: 

an allocating module configured to allocate 
the resource upon a determination that it was not 
previously allocated. 

20 

1 5. The apparatus of claim 1 1 , wherein the resource al- 
locator includes: 

an incrementing module configured to incre- 
ment a reference count corresponding to the re- 
?5 source, the reference count indicating how many 
processes currently have references to the re- 
source. 



requesting from a process access to a resource 
for a lease period; 

receiving from the process a granted lease pe- 
riod during which shared access to the re- 
source is permitted; and 
sending a request to the process for a new 
lease period upon a determination that the 
granted lease period is about to expire but ac- 
cess to the resource has not completed. 



16. The apparatus of claim 15, further comprising: 

30 

a second receiving module configured to re- 
ceive a second request from the process indi- 
cating that the process wishes to terminate its 
access to an identified resource; and 
35 a decrementing module configured to decre- 

ment the reference count corresponding to the 
identified resource. 



10. The method of claim 9, further comprising the step ' 
of: 40 

prior to expiration of the granted lease period, 
sending a different request indicating that shared 
access to the resource is no longer requested. 

11. An apparatus comprising: « 

a receiving module configured to receive a re- 
quest from a process referring to a resource 
and specifying a requested lease period; 
a resource allocator configured to permit so 
shared access to the resource for a granted 
lease period; 

an advising module configured to advise the 
process of the granted lease period, and 
a resource deallocator configured to deallocate $s 
the resource when the granted lease period ex- 
pires. 



17. The apparatus of claim 11, wherein the resource 
deallocator includes: 

an invoker configured to invoke a garbage col- 
lection process to reclaim the resource when 
shared access to the resource is no longer request- 
ed. 

18. The apparatus of claim 16. wherein the resource 
deallocator includes: 

an invoker configured to invoke a garbage col- 
lection process to deallocate the identified resource 
when the reference count indicates no processes 
currently access to the identified resource. 

19. An apparatus comprising; 

a requesting module configured to request from 
a process access to a resource for a lease pe- 
riod; 

a receiving module configured to receive from 
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the process a granted lease period during 
which shared access to the resource is permit- 
ted; and 

a second sending module configured to send 
another request to the process for a new lease 
period upon a determination that the granted 
lease period is about to expire but access to the 
resource has not completed. 

The apparatus of claim 19, further comprising; 

a second sending module configured to send 
a different request indicating that shared access to 
the resource is no longer requested prior to expira- 
tion of the granted lease period. 

21. A computer program product comprising: 

a computer usable medium having computa- 
ble readable code embodied therein for managing 
resources, the computer usable medium compris- 
ing: 

a receiving module configured to receive a re- 
quest from a process referring to a resource 
and specifying a requested lease period; 
a resource allocator configured to permit 
shared access to the resource for a granted 
lease period; 

an advising module configured to advise of the 
granted lease period; and 
a resource deallocator configured to deallocate 
the resource when the granted lease period ex- 
pires. 
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26. The computer program product of claim 25. th 
computer usable medium further comprising: 

a second receiving module configured tc /e 
ceive a second request from the process indi- 
cating that the process wishes to terminate its 
access to an identified resource; and 
a decrementing module configured to decre 
ment the reference count corresponding to the 
identified resource. 

27. The computer program product of claim 21 , wherein 
the resource deallocator includes: 

an invoker configured to invoke a garbage col- 
lection process to reclaim the resource when 
shared access to the resource is no longer request- 
ed. 



28. 



20 



25 



The computer program product of claim 26 : wherein 
the resource deallocator includes: 

an invoker configured to invoke a garbage col- 
lection process to deallocate the identified resource 
when the reference count indicates no processes 
currently access the identified resource. 



30 



22. 



The computer program product of claim 21 , wherein 
the resource allocator includes: 35 

a determining module configured to deter- 
mine the granted lease period to be a period less 
than the requested lease period. 



23. The computer program product of claim 21, wherein 40 
the resource allocator includes: 

a determining module configured to deter- 
mine the granted lease period based on at least one 
of the requested lease period, a measure of the re- 
source, and other granted lease periods for the re- 45 
source. 



24. 



The computer program product of claim 21 , wherein 
the resource allocator includes: 

an allocating module configured to allocate so 
the resource upon a determination that it was not 
previously allocated. 



29. A computer program product comprising: 

a computer usable medium having computa- 
ble readable code embodied therein for managing 
resources, the computer usable medium compris- 
ing: 

a requesting module configured to request from 
a process access to a resource for a lease pe- 
riod; 

a receiving module configured to receive from 
the process a granted lease period during 
which the process permits shared access to the 
resource; and ■ 

a sending module configured to send another 
request to the process for a new lease period 
upon a determination that the granted lease pe- 
riod is about to expire. 

30. The computer program product of claim 29, the 
computer usable medium further comprising: 

a second sending module configured to send 
a different request indicating that shared access to 
the resource is no longer requested prior to expira- 
tion of the granted lease period. 



31. 



25. The computer program product of claim 21 . wherein 
the resource allocator includes: 

a reference count module configured to indi- 
cate a number of processes that currently have ref- 
erences to the resource. 



55 



A computer system comprising: 
a computer processor: 

a memory which is operatively coupled to the 
computer processor; and 
a computer process which executes in the com- 
puter processor for the memory and whicn in- 
cludes: 
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a receiving module configured to receive a 
request from a process referring to a re- 
source and specifying a requested lease 
period; 

a resource allocator configured to permit s 
shared access to the resource for a grant- 
ed lease period; 

an advising module configured to advise of 
the granted lease period; and 
a resource deallocator configured to deal- w 
locate the resource when the granted lease 
period expires. 

32. The computer system of claim 31, wherein the re- 
source allocator includes; 

a determining module configured to deter- 
mine the granted lease period to be a period less 
than the requested lease period. 

33. The computer system of claim 31, wherein the re- 
source allocator includes; 

a determining module configured to deter- 
mine the granted lease period based on at least one 
of the requested lease period, a measure of the re- 
source, and other granted lease periods for the re- 
source. 



source deallocator includes; 

an invoker configured to invoke a garbage col- 
lection process to deallocate the identified resource 
when the reference count indicates no processes 
currently access the identified resource. 

39. A computer system comprising; 

a computer processor; 

a memory which is operatively coupled to the 
computer processor; and 
a computer process which executes in the com- 
puter processor for the memory and which in- 
cludes; 

a requesting module configured to request 
from a process access to a resource for a 
lease period; 

a receiving module configured to receive 
from the process a granted lease period 
during which the process permits shared 
access to the resource: and 
a sending module configured to send an- 
other request to the process for a new 
lease period upon a determination that the 
granted lease period is about to expire. 



34. The computer system of claim 31, wherein the re- 
source allocator includes; 

an allocating module configured to allocate 
the resource upon a determination that it was not 
previously allocated. 

35. The computer system of claim 31. wherein the re- 
source allocator includes: 

a reference count module configured to indi- 
cate a number of processes that currently have ref- 
erences to the resource. 

36. The computer system of claim 35, wherein the com- 
puter process further includes: 

a second receiving module configured to re- 
ceive a second request from the process indi- 
cating that the process wishes to terminate its 
access to an identified resource; and 
a decrementing module configured to decre- 
ment the reference count corresponding to the 
identified resource. 

37. The computer system of claim 31 1 wherein the re- 
source deallocator includes: 

an invoker configured to invoke a garbage col- 
lection process to reclaim the resource when 
shared access to the resource is no longer request- 
ed. 

38. The computer system of claim 36, wherein the re- 



40. The computer system of claim 39, wherein the com- 
puter process further includes: 
30 a second sending module configured to send 

a different request indicating that shared access to 
the resource is no longer requested prior to expira- 
tion of the granted lease period. 

35 41. In a distributed processing system having a plurality 
of platforms, a method for allocating and deallocat- 
ing resources distributed among the platforms com- 
prising the steps, performed by server platforms, of: 

4 ° (a) receiving requests from requestor platforms 

including references to system resources and 
requested lease periods, the requests indicat- 
ing that the corresponding requestor platform 
seeks access to the referenced system re- 

4 5 source for the requested period of time in the 

request: 

(b) allocating each of the referenced system re- 
sources by 

50 (i) setting a corresponding grant period in 

response to each of the requested lease 
periods, the grant period indicating an in- 
terval for which each of the referenced sys- 
tem resources associated with requests 

55 will be available for access by the plat- 

forms, and 

(ii) incrementing a corresponding refer- 
ence counter, the reference counter indi- 



11 



21 



EP0 836 140 A2 



eating a number of the platforms accessing 
the corresponding system resource as de- 
termined by the receipt of requests: 

(c) sending responses to the requestor plat- s 
forms, in response to associated requests, 
specifying the grant periods for the resources 
referenced in the associated requests; 

(d) initiating a garbage collection process to 
deallocate each of the referenced system re- to 
sources when 

(i) the grant period for each referenced sys- 
tem resource expires, or 

(ii) the corresponding reference counter is '5 
a state indicating that no requestor plat- 
forms currently seek access to each of the 
referenced system resources. 

42. The method of claim 31, further comprising the 20 
steps of; 

(e) receiving new requests from the requestor 
platforms including references to the system re- 
sources and indicating that the requestor plat- 25 
forms request to terminate access to the sys- 
tem resources of the new requests; and 

(f) decrementing the reference counter corre- 
sponding to each of the referenced system re- 
sources specified in the new requests. 30 
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